System and method for domain management and migration

ABSTRACT

A system and method for managing domain registrations across multiple domain registrars, and for migrating domains from one or more server computers to one or more other server computers. More specifically but not exclusively, disclosure relates to software processes, algorithms, and protocols for the management and movement of domains, as accessed across a network.

FIELD OF THE INVENTION

The field of invention relates generally to a system and method formanaging domain registrations across multiple domain registrars, and formigrating domains from one or more server computers to one or more otherserver computers. More specifically but not exclusively, the inventionrelates to software processes, algorithms, and protocols for themanagement and movement of domains, as accessed across a network.

BACKGROUND INFORMATION

In recent years the number of domains has grown significantly. Someestimates put the total number of top level domains worldwide, as ofMarch, 2006 at more than 65 million. A domain is a name, such as“www.company.com”, by which a computer connected to the Internet isidentified. In this example, “www” indicates the domain is a World WideWeb address, “company” is the name of the company to which the domain isregistered, and “.com” indicates that the domain belongs to the “.com”group of commercial domains. Other extensions besides “.com” include“.org”, “.edu”, “.info” and so on. More recently, 700 new domainextensions have been announced to be available in the near future.

Domain names are the human readable analog to Internet Protocol (IP)addresses, such as “256.112.10.1”. To be usable, a domain must beregistered with one of the numerous accredited domain name registrars,such a “Godaddy.com” or “Register.com”. A user desiring to use aparticular domain name typically goes to the web site of one of theseregistrars, finds a desired available domain name and purchases thedomain name. The user then owns the rights to that domain name for aparticular period of time, typically, one, two, five, or ten years; thedomain registrar lists the domain with the domain authority for theparticular domain group. The domain may then be maintained by the uservia the web based interface of the registrar with whom which the domainwas registered. Some domain name owners register hundreds, thousands, ortens of thousands of domains in the hope that they will be able to makemoney from the domains by placing advertising on them, or by selling thedomains in the future.

Alternatively, a prospective domain name owner may purchase the rightsto a domain name on an after-market, auction, or domain selling site,such as “Afternic.com”, “Snapnames.com”, or “Pool.com”, obtaining therights to the domain from another owner. When a purchase occurs, therights to the domain transfer to the new owner in exchange for money,while the domain registration and record itself remains with the domainregistrar where the domain was registered.

As a result, the owners of domains often end up with tens or hundreds ofdomains registered with different registrars. Because domains typicallyexpire on the one year, two year, five year, or ten year anniversary oftheir registration date, the owner of numerous domains must deal withthe numerous different interfaces and accounts of the registrationmanagement systems of different registrars. Working with theseinterfaces can be cumbersome and difficult, while trying to managedomains across multiple registrars can lead to confusion, resulting in afailure to renew a domain before it expires, causing the loss of one ormore valuable domain names. The solution to the aforementioned problemis the subject of the present invention.

Many owners of domains host their domains, that is, put the web pagesfor the web sites that their domain names point to, on servers at aremote location connected to the Internet. “Godaddy.com” is an exampleof one company that provides both registration services and hosting;Dreamhost is another company that provides hosting services. Hostedservers are typically managed by a company, with a user paying a monthlyor yearly fee to the company that owns the servers in exchange foraccess to the server for a particular period of time, such as a month ora year. The hosting company typically sets up and maintains the server,and often provides additional services such as installing specialsoftware, checking for security holes, and updating software, for anadditional fee. Thus, in the aforementioned example, a user withmultiple web sites may have a web site located on a plurality ofGodaddy.com hosted servers, as well as on a plurality of Dreamhosthosted servers, as well as on the servers of other hosting companies.

From time to time, a purchaser of such hosting services desires tomigrate web sites from one machine to another. There are a number ofcases in which such a purchaser would want to migrate web sites from onemachine to another. One case is when a machine on which web sites arerunning becomes out of date. Another case is when a machine for which apurchaser has paid for a particular period of time, such as a year,comes up for renewal. In this case, the hosting provider often chargesmore for a renewal of the existing machine than for the purchase of anew machine (often with newer and better hardware), because the hostingprovider knows that it is difficult for the purchaser to switchmachines. The present invention also solves the aforementioned problem.

SUMMARY OF THE INVENTION

In accordance with aspects of the present invention, a system and methodis described for managing domain registrations across multiple domainregistrars. In another aspect of the present invention, a system andmethod is described for migrating domains from one or more servercomputers to one or more other server computers.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of thisinvention will become more readily appreciated as the same becomesbetter understood by reference to the following detailed description,when taken in conjunction with the accompanying drawings, wherein likereference numerals refer to like parts throughout the various viewsunless otherwise specified:

FIG. 1 is a schematic drawing of the system for domain management andmigration.

FIG. 2 a is a flowchart illustrating the process for centralizedmanagement and viewing of domains and associated registrationinformation across a plurality of domain registrars.

FIG. 2 b shows an alternative embodiment for displaying the webinterfaces of a plurality of domain registrars via a unified displayinterface.

FIG. 3 is a flowchart illustrating the process for renewing a pluralityof domains on different registrars.

FIG. 4 is a flowchart illustrating the process for modifying the DNSsettings for a domain at a supported registrar.

FIG. 5 a is a flowchart illustrating the process for determining anddisplaying the differences between two server configurations, formigrating the files and database tables associated with a web site fromone server machine to another server machine, and for updatingassociated DNS settings.

FIG. 5 b is a flowchart showing a continuation of the process from FIG.5 a.

FIG. 6 is a flowchart showing a continuation of the process from FIG. 5b.

FIG. 7 is a visual representation of the interface for displayinginformation about domain registrations retrieved from a plurality ofdomain registrars.

FIG. 8 is a flowchart showing the process for automatically uploadingfiles for migration to a server.

FIG. 9 is a flowchart showing the process for first de-compressing fileslocally before automatically uploading them to a server.

FIG. 10 is a flowchart showing the process for automatically updatingDNS information once a migration has been completed.

FIG. 11 a is a frontal isometric view of an exemplary blade serverchassis in which a plurality of server blades are installed.

FIG. 11 b is a rear isometric view of the blade server chassis of FIG.11 a.

FIG. 11 c is an isometric frontal view of an exemplary blade server rackin which a plurality of rack-mounted blade server chassis correspondingto FIGS. 11 a and 11 b are installed.

FIG. 12 shows details of the components of a typical server blade,according to one embodiment.

DETAILED DESCRIPTION

Embodiments of methods and apparatus for domain management and migrationare described herein. In the following description, numerous specificdetails are set forth to provide a thorough understanding of embodimentsof the invention. One skilled in the relevant art will recognize,however, that the invention can be practiced without one or more of thespecific details, or with other methods, components, materials, etc. Inother instances, well-known structures, materials, or operations are notshown or described in detail to avoid obscuring aspects of theinvention.

Reference throughout this specification to “one embodiment” or “anembodiment” means that a particular feature, structure, orcharacteristic described in connection with the embodiment is includedin at least one embodiment of the present invention. Thus, theappearances of the phrases “in one embodiment” or “in an embodiment” invarious places throughout this specification are not necessarily allreferring to the same embodiment. Furthermore, the particular features,structures, or characteristics may be combined in any suitable manner inone or more embodiments.

FIG. 1 illustrates an exemplary domain management and migration system100. System 100 includes management server 110, hosted server 130,hosted server 150, and domain registrars 172, 182, and 192. Managementserver 110 includes operating system 112, which represents any of a widevariety of commonly available operating systems such as, by way ofexample and without limitation, Red Hat Enterprise Linux from Red Hat,Inc., web server software 114, which represents any of a wide variety ofweb server products such as the Apache Web Server from the Apache ServerFoundation, additional modules 116, database 118, which represents anyof a wide variety of databases, such as a database implemented throughMySQL, from MySQL Corporation, web interface 120, through which usersview and manage domains, and migrate web sites, databases, and settingsbetween servers, and migration manager 122, which is implemented in PHP,a widely used general-purpose scripting language supported by The PHPGroup. Web interface 120 of management server 110 is accessed over theInternet 196, by a user on a desktop PC 198 running web browser 126,which represents a wide variety of commonly available web browsers suchas Internet Explorer 8, 9 or 10 from Microsoft Corporation, GoogleChrome, Mozilla Firefox, Apple Safari, Mobile Safari, Android Browser,and Mobile Chrome, etc.

Hosted server 130 includes operating system 132, web server 134, modules136, database 138, and a plurality of domains, “DOMAIN1.COM” 140,“DOMAIN2.COM” 142, and “DOMAIN3.COM” 144. Hosted server 150 includesoperating system 152, web server 154, modules 156, database 158, and,after the migration process described below completes, domains 160, 162,and 164.

Domain registrar 172 includes registration servers 170, web servicesinterface 174 and web interface 176. Likewise, domain registrar 182includes servers 180, web services interface 184, and web interface 186.Domain registrar 192 includes servers 190, and web interface 194.

According to one implementation of the invention, as shown in FIG. 2 a,drawing 200, if the user is not yet registered to use migration manager122 (decision point 210), migration manager 122 allows the user toregister (operation 242) via web interface 120. If the user is alreadyregistered, then migration manager 122 accepts a user login (operation212) from the user of computer 198 via web interface 120 served by webserver 114 to web browser 126 over the Internet 196.

Via web interface 120, migration manager 122 displays the list ofdomains stored in database 118 for the user of computer 198, (operation214) associated with the user's accounts on domain registrars 172, 182,or 192. If the user choose to add new domains (decision point 216), thenweb interface 120 allows the user to choose a domain from a dropdownlist of supported domain registrars (operation 218). Migration manager122 prompts the user for account information (operation 220) and storesthe account information received from the user in database 118.

Migration manager 122 on management server 110 supports two methods forretrieving domain registration information from registrars 172, 182, and192. If the registrar supports a web services interface (decision pint224), that is, a method for programmatically processing a request fordomain registration information via XML over the HTTPS protocol, as withregistrars 172 and 182, then migration manager 122 interfaces with webservices interfaces 174 and 184 respectively to retrieve domainregistration information via web services (operation 228). Migrationmanager 122 also retrieves the expiration dates of each domain from thesupported registrar and displays the list of domain registrations asshown in drawing 700 of FIG. 7.

Alternatively, if the domain registrar does not support a web servicesinterface, as with domain registrar 192, migration manager 122 loadsscreen-scraping module 124 from modules 116 to interface with domainregistrar 192 (operation 234). Module 124 loads file 126 (operation 236)containing data specifically describing the web interface of registrar192. In the instant implementation, screen-scraping module 124 mimics auser interfacing with domain registrar 192; module 124 parses receivedweb pages looking for specific tag words and phrases including“account”, “username”, “password”, and “domain name”, based on theregistrar-specific data in file 126. Module 124 transmits user accountname and password to servers 190 of registrar 192 over network 196;module 124 parses the page that is returned by servers 190 (operation238) and additionally retrieves the expiration date of each domain(operation 240), displaying the returned domain data to the user via webinterface 120 (operation 232); the domain data appears in unifiedinterface 700 of FIG. 7 on the web browser 126 of user's computer 198.

In an alternative embodiment, as shown in FIG. 2 b, drawing 260,migration manager 122 neither interfaces with registrars 172, 182 and192 via a web interface nor via screen-scraping. Instead, migrationmanager 122 retrieves a list of registrars from database 118 (operation270), creates a display frame (operation 272) for each registrar, anddisplays registrar specific information in display pane 720 (operation274) accessible via individual tabs 712, 714, and 716 inside webinterface 120.

As shown in FIG. 3, drawing 300, a plurality of domain names can bedisplayed in multiple ways and renewed via a unified interface.Migration manager 122 accepts input from the user (operation 310)indicating whether to display domains sorted by domain name or byregistrar (decision point 312). If the user elects to view domain namessorted alphabetically by domain name, migration manager 122 displays viaweb interface 120 the domains associated with the user's account intoweb browser 126 (operation 330), as shown in FIG. 7 drawing 700. If theuser chooses to view domain names by registrar, migration manager 122displays via web interface 120 the domains associated with the user'saccount into web browser 126 sorted by registrar name (operation 314) asshown in FIG. 7 drawing 704.

Migration manager 122 waits for the user to choose to renew a domainname and accepts the user selection of which domain name to renew(operation 316). Migration manager 122 loads the connector for thespecified domain (operation 318) and the connector determines if theregistrar for the selected domain name can be renewed via web services(programmatic) interface 176 or 186 of registrars 172 and 182respectively. If the registrar supports a web services interface(decision point 320), migration manager 122 sends an XML over HTTPScommand to the specified registrar, e.g. registrar 172, containing theusername and password of the user account for the specified registrarand the name of the domain to renew, as shown in FIG. 7 drawing 724(operation 322). If the registrar does not support a web servicesinterface, as is the case with registrar 192, migration manager 122loads configuration file 126 and renews the specified domain viascreen-scraping (operation 326). The result of the renewal attempt isdisplayed to the user of computer 198 via web interface 120 in browser126 via the Internet 196 (operation 328).

As shown in FIG. 4, drawing 400, migration manager 122 supports theupdating of Domain Name System (DNS) data on supported registrars orreversion to old DNS data if selected by the user for a given domainname. Migration manager 122 retrieves a list of domains associated withthe user's account and displays them to the user (operation 410) via webinterface 120. Migration manager 122 waits for the user to choose one ofthe domains for DNS updating by clicking on the DNS information for aparticular domain as shown in FIG. 7 hyperlink 702, and then displaysthe DNS data for the selected domain (operation 414), as shown in FIG. 7drawing 730, which shows the domain name and two name server names andtheir IP addresses in a popup window. If the user chooses to revert toan old DNS configuration (decision point 416), migration manager 122retrieves the old DNS configuration data for the specified domain fromdatabase 118 (operation 420). If the user chooses to provide new DNSdata, migration manager 122 receives the new DNS information via webinterface 120 presented in web browser 126 over the Internet 196(operation 418). Migration manager 122 loads connector 124 whichdetermines whether the registrar associated with the domain for whichDNS information is to be renewed supports a web services interface(decision point 424); if the registrar, e.g. registrar 172 supports aweb services interface 174, the DNS information for the specified domainis updated via web services interface 174 (operation 428). If not, as inthe case of registrar 192, connector 124 loads configuration file 126and updates the DNS information via web interface 194 of registrar 192(operation 430). The result of the DNS update attempt (either success orfailure) is displayed to the user (operation 432), completing theprocess.

As shown in FIG. 5, drawing 500, migration manager 122 migrates domainsincluding web site related files and database tables from server 130 toserver 150, automating what prior to the instant invention was a tediousmanual process for system administrators. Migration manager 122retrieves a list of domains for the user from database 118 (operation510) and displays them to the user (operation 512). If the user choosesto migrate an existing domain (that is, one that exists in database118), then migration manager 122 accepts the source selection from thedisplayed list in web interface 120 (operation 516) otherwise migrationmanager 122 accepts via web interface 120 the IP address (such as224.38.12.18) or fully qualified domain name (FQDN) of a web site suchas DOMAIN1.COM 140 hosted on server 130, from which migration manager122 deduces the IP address of web site 140 (operation 516).

Migration manager 122 allows the user of computer 198 interacting withmigration manager 122 to migrate all the web sites on server 130 orindividual web sites, e.g. site 140. Migration manager 122 thus acceptsa username and password specific to “DOMAIN1.COM” 140 from the user ofcomputer 198, or a username and password that grants access to multipleor all web sites of server 130 (operation 518).

In the case where migration manager 122 receives indication from theuser to migrate all web sites 140, 142 and 144 on server 130 to server150 (decision point 520), the following process ensues. Migrationmanager 122 first accepts input from the user of computer 198 indicatingdestination server 150 to which sites 140, 142 and 144 are to bemigrated; that is, migration manager via web interface 120 allows theuser of computer 198 via browser 126 over network 196 to select anexisting server displayed in interface 120 (operation 524) or to add anew server (decision point 522), inputting IP address or domain name(operation 526), username and password information for the new server(operation 528).

Continuing in FIG. 5 b, drawing 548, migration manager 130 supportsthree ways of detecting the domains available on server 130 formigration. One way (decision point 530) is that migration manager 122accepts via manual input into web interface 120 from the user the listof individual domains with associated usernames and passwords (operation536); a second way (decision point 532) is that the user provides anadministrative username and password that allows migration manager 122to access all domains on server 130 (operation 538); a third way(decision point 534) is via screen-scraping interfacing with web-basedcontrol panel 128 of server 130, which web-based control panel 128represents a wide variety of common server control panel softwareprograms including Plesk and cPanel; migration manager 122 accepts viaweb interface 120 the username, password and IP address of control panelinterface 128 of server 130, then accesses control panel 128 and scrapesthe domain data from control panel 128 (operation 540). Migrationmanager accepts from the user via web interface 120 the selection ofdomain detection mechanism (decision points 530, 532, 534).

Migration manager 122 supports two migration modes: active migrationmode and passive migration mode. Both modes are supported on aper-domain or per-server basis. In active mode, migration manager 122has sufficient access privileges to perform various actions directly onsource server 130. In passive mode, migration manager 122 does not havesufficient privileges and therefore relies on downloading files via FileTransfer Protocol (FTP).

Migration manager 122 waits for the user to initiate the migrationprocess; once the process is initiated, migration manager 122 acceptsinput from the user of computer 198 indicating whether to run in activeor passive mode (decision point 552), and whether to migrate files onlyor the structure and content of the tables contained in database 138 aswell. Migration manager 122 also accepts input from the user indicatingwhether the configuration of cronjobs (that is, scheduled tasks) shouldbe migrated.

Running on a per-server basis, in active migration mode, migrationmanager 122, having sufficient privileges on server 130 accesses server130 via a secure shell connection. If the user has indicated thatmigration manager 122 should migrate database tables (decision point552), then migration manager 122 runs the “mysql” command (operation554), providing the root username and password supplied by the user, andreturns over network 196 a list of database tables to the user ofcomputer 198 via web interface 120 (operation 556). That is, webapplication 122 receives a list of tables back, presents them viainterface 120 to the user of computer 198. Migration manager 122 acceptsinput (operation 558) from the user indicating which tables to migrateand then runs the mysql “dump” command (operation 560) with theuser-selected tables, causing the creation of a database dump file.Migration manager 122 then runs the “tar” and “gzip” commands tocompress the file for transfer (operation 562).

Having completed the database dump process, migration manager 122indicates via interface 120 to the user that the migration process isproceeding to the file processing operation (operation 564). Migrationmanager 122 changes to the highest accessible directory, and then,recursively, for each “httpdocs” sub-directory found executes the “tar”command (operation 566) to wrap all the files associated with domain 140into a single file, the name of which is the name of the domain with a.tar.gz extension; it then runs the “gzip” command to compress the “tar”file (operation 568). Migration manager 122 thus produces three files onserver 130, DOMAIN1.COM.tar.gz; DOMAIN2.COM.tar.gz, andDOMAIN3.COM.tar.gz.

Running on a per-domain basis (decision point 570), in active migrationmode, migration manager 122 accesses each domain of server 130(operation 572), that is domains 140, 142, and 144, repeats theaforementioned database dump process (decision point 574), and runs the“tar” command in the “httpdocs” directory, creating a file, the name ofwhich is the name of the domain with a .tar.gz extension. ForDOMAIN1.COM 140, the resulting file is DOMAIN1.COM.tar.gz; forDOMAIN2.COM 142, it is DOMAIN2.COM.tar.gz and for DOMAIN3.COM 144 it isDOMAIN3.COM.tar.gz.

If the target of the migration process is also accessible via activemode (decision point 576) (that is, migration manager 122 has sufficientpermissions to run necessary commands), then migration manager 122connects to server 150 via a secure shell connection (operation 578).Migration manager 122 executes the “wget” command (operation 580)providing the IP address, username, and password of server 130; it thenscripts the “wget” command causing it to download (operation 582) thecompressed database file, as well as the per-domain “.tar.gz” files onserver 130 to server 150. Migration manager 122 determines (decisionpoint 584) if the target domains already exist on destination server 150(that is, if they have already been created by the user); if they havenot, then for any domains that do not yet exist (as determines by theexistence of sub-directories named the domain name of the downloadedfiles), migration prompts the user to determine if the user wants tocreate the domains prior to proceeding or if migration manager shouldcreate the domains (decision point 586). If the user chooses to createthe domains manually (e.g. outside the migration manager), migrationmanager waits until the user indicates the domains have been created,then checks for their existence and repeats if necessary. Alternatively,migration manager 122 creates the domains by creating the necessarysubdirectories corresponding to the domains, that is DOMAIN3.COM,DOMAIN2.COM, and DOMAIN1.com (operation 588).

With the domains existing, migration manager 122 executes the “gunzip”and “tar-xvf’ commands to first de-compress and then separate the tarfile into its file components into the appropriate sub-domains for eachfile corresponding to the domain (operation 590). That is,“DOMAIN3.COM.tar.gz” is first de-compressed then un-tarred into thedirectory “www.domain3.com”, filling slot 164. The process is repeatedfor each domain file, filling slots 162, and 160 respectively.

If database migration was selected by the user, migration manager 122runs the “gunzip” and “tar” commands to decompress and separate the dumpfile from the tar container (operation 592). Migration manager 122checks for the existence of the necessary databases in mysql byexecuting the “mysql” command. If the databases do not yet exist,migration manager 122 creates them and then imports the database dumpfile into the mysql database, creating a replicate of database 138 indatabase 158 (operation 594). The web site content and database tablesof server 130 have now been migrated to server 150.

Continuing, in FIG. 6, drawing 600, in some cases, the user cannot ordoes not want to supply sufficient access rights to either server 150 orserver 130. In this case, migration manager 122 operates in passivemode, using management server 110 as an intermediary storage location.It is to be understood that one server can be operated in passive modewhile the other is operated in active mode; both may be operated inactive mode; or both in passive mode.

If management server 110 does not have sufficient access permissions onserver 130 to operate in active mode, migration manager 122 operates inpassive mode. In passive mode, migration manager 122 connects to server130 using the File Transfer Protocol (FTP), using the domain name or IPaddress of the web site specified by the user for migration (operation610). Migration manager 122 creates a local directory on managementserver 110 to store the files that will be downloaded from each domain(operation 612). Migration manager 122 changes to the remote “httpdocs”directory and uses the “mget” command to retrieve all files for theselected web site, downloading them to server 110 individually(operation 614). Migration manager 122 repeats this operation for eachweb site; that is, for DOMAIN2.COM 142 and DOMAIN1.COM 140 respectively,downloading the files into the selected local directory for thespecified domain (decision point 616).

If migration manager 122 has sufficient privileges to access server 150in active mode, then migration manager 122 runs the “tar” and “gzip”commands locally (on management server 110) so that migration manager122 can upload fewer, compressed files to server 150, rather than onefile at a time (operation 618). Migration manager 122 connects to server150 and creates DOMAIN1.COM 160, DOMAIN2.COM 162, and DOMAIN3.COM 165(operation 622), respectively, if they do not already exist (decisionpoint 620) and the action to create the domains is approved by the uservia a window prompt. Migration manager 122 then uploads the “.tar.gz”file for each domain to the “httpdocs” directory of the specified domain(operation 624). That is, for DOMAIN1.COM 160, migration manager 122uploads a file called “DOMAIN1.COM.tar.gz” which contains all web sitefiles for DOMAIN1.COM 140; migration manager 122 repeats the process forDOMAIN2.COM 162 and DOMAIN3.COM 164. Migration manager 122 then runs thecommands previously described to un-zip and un-tar the files for eachdomain (operation 626).

In an alternative embodiment, as shown in FIG. 8, if server 150 cannotbe accessed in active mode, and files were downloaded from server 130 inpassive mode, then migration manager 122 runs in passive mode. In thismode, migration manager 122 connects to each domain 160, 162, and 164one at a time (operation 810) and each file for each domain is uploadedindividually from server 110 to server 150 via the File TransferProtocol (operation 812). In this embodiment, DOMAIN1.COM 160,DOMAIN2.COM 162 and DOMAIN3.COM 164 must already exist on server 150,having been created by the user. After migration manager 122 hascompleted uploading the files for a given domain, it disconnects fromthe specified domain (operation 814) and checks if there are moredomains for which files need to be uploaded (decision point 816). Ifthere are more domains to be processed, then migration manager 122 getsthe next domain name (operation 818) and repeats the process until thereare no more domain names.

In an alternative embodiment shown in FIG. 9, drawing 900, if server 150cannot be accessed in active mode, and files were downloaded from server130 in active mode, then migration manager 122 runs in passive mode.Migration manager 122 first un-zips (operation 910) and un-tars(operation 912) all files for DOMAIN1.COM 140, DOMAIN2.COM 142, andDOMAIN3.COM 144 locally on server 110. Migration manager 122 then usesthe File Transfer Protocol to connect to the first domain on server 150(operation 914) and uploads the individual files to slot 160,corresponding to the first domain (operation 916) to be migrated.Migration manager 122 then disconnects from domain 160 and checks ifthere are more files for more domains to be uploaded (decision pint920); if there are, then migration manager 122 gets the next domain name(operation 922) and repeats the process. The domains must already havebeen created by the user. This completes the migration process.

With the migration process completed, in another implementation shown inFIG. 10, drawing 1000, migration manager 122 connects to registrars 172,182, and 192 (operation 1010) and updates the Domain Name Services (DNS)information for each of domains 140, 142, and 144 to point to thesedomains 160, 162, and 164 respectively, on server 150 (operation 1012).

Exemplary Implementation Environment and Blade Server Architecture

It is envisioned that aspects of the embodiments herein may beimplemented in various types of computing environments, includingon-premise equipment such as computers and servers communicativelycoupled via a LAN, as well as blade servers and modules employed in adata center and/or server farm environment, such as used for hostingcloud-based services. Typically, the servers used in data centers andserver farms comprise arrayed server configurations such as rack-basedservers including multiple server blades or modules. These servers areinterconnected in communication via various network provisions, such aspartitioning sets of servers into LANs with appropriate switching androuting facilities between the LANs to form a private Intranet. Forexample, cloud hosting facilities may typically employ large datacenters with a multitude of servers.

As an overview, typical blade server components and systems are shown inFIGS. 11 a-c, and 12. Under a typical configuration, a rack-mountedchassis 1100 is employed to provide power and communication functionsfor a plurality of server blades (i.e., blades) 1102, each of whichoccupies a corresponding slot. (It is noted that all slots in a chassisdo not need to be occupied.) In turn, one or more chassis 1100 may beinstalled in a blade server rack 1103 shown in FIG. 11 c. Each blade iscoupled to an interface plane 1104 (e.g., a backplane or mid-plane) uponinstallation via one or more mating connectors. Typically, the interfaceplane will include a plurality of respective mating connectors thatprovide power and communication signals to the blades. Under currentpractices, many interface planes provide “hot-swapping”functionality—that is, blades can be added or removed (“hot-swapped”) onthe fly, without taking the entire chassis down through appropriatepower and data signal buffering.

A typical mid-plane interface plane configuration is shown in FIGS. 11 aand 11 b. The backside of interface plane 1104 is coupled to one or morepower supplies 1106. Oftentimes, the power supplies are redundant andhot-swappable, being coupled to appropriate power planes andconditioning circuitry to enable continued operation in the event of apower supply failure. In an optional configuration, an array of powersupplies may be used to supply power to an entire rack of blades,wherein there is not a one-to-one power supply-to-chassiscorrespondence. A plurality of cooling fans 1108 are employed to drawair through the chassis to cool the server blades.

An important feature required of all blade servers is the ability tocommunicate externally with other IT infrastructure. This is typicallyfacilitated via one or more network connect cards 1110, each of which iscoupled to interface plane 1104. Generally, a network connect card mayinclude a physical interface comprising a plurality of network portconnections (e.g., RJ-45 ports), or may comprise a high-densityconnector designed to directly connect to a network device, such as anetwork switch, hub, or router.

Blade servers usually provide some type of management interface formanaging operations of the individual blades. This may generally befacilitated by a built-in network or communication channel or channels.For example, one or more buses for facilitating a “private” or“management” network and appropriate switching may be built into theinterface plane, or a private network may be implemented throughclosely-coupled network cabling and a network. Optionally, the switchingand other management functionality may be provided by a managementswitch card 1112 that is coupled to the backside or front-side of theinterface plane. As yet another option, a management or configurationserver may be employed to manage blade activities, whereincommunications are handled via standard computer networkinginfrastructure, for example, Ethernet.

With reference to FIG. 12, further details of an exemplary blade 1200are shown. As discussed above, each blade comprises a separate computingplatform that is configured to perform server-type functions, i.e., is a“server on a card.” Accordingly, each blade includes components commonto conventional servers, including a main printed circuit board (mainboard) 1201 providing internal wiring (i.e., buses) for couplingappropriate integrated circuits (ICs) and other components mounted tothe board. These components include one or more processors 1202 coupledto system memory 1204 (e.g., some form of Random Access Memory (RAM)),cache memory 1206 (e.g., SDRAM), and a firmware storage device 1208(e.g., flash memory). A NIC (network interface controller) chip 1210 isprovided for supporting conventional network communication functions,such as to support communication between a blade and external networkinfrastructure. Other illustrated components include status LED(light-emitting diodes) 1212, a set of RJ-45 console ports 1214 (onlyone of which is shown for simplicity), and a NIC 1215 coupled to aninterface plane connector 1216. Additional components include variouspassive components (i.e., resistors, capacitors), power conditioningcomponents, and peripheral device connectors. Processor 1202 maytypically comprise a multi-core processor having a System on a Chip(SoC) architecture.

Generally, each blade 1200 may also provide on-board storage. This istypically facilitated via one or more built-in disk controllers andcorresponding connectors to which one or more disk drives 1218 arecoupled. For example, typical disk controllers include SATA controllers,SCSI controllers, and the like. As an option, the disk drives may behoused separate from the blades in the same or a separate rack, such asmight be the case when a network-attached storage (NAS) appliance orbackend storage sub-system that is employed for storing large volumes ofdata. Disk drives 1218 may be Solid State Drives (SSDs), magnetic drivesor optical drives. Optionally, other types of solid state mass storagedevices may be used.

In a typical data center deployment, network switching elements compriserack-mounted equipment, such as would occupy a 1U, 2U, or 4U slot, ormay be implemented via one or more server blades. Optionally, a networkswitching element may be implemented use one or more server blades.

Although some embodiments have been described in reference to particularimplementations, other implementations are possible according to someembodiments. Additionally, the arrangement and/or order of elements orother features illustrated in the drawings and/or described herein neednot be arranged in the particular way illustrated and described. Manyother arrangements are possible according to some embodiments.

It is noted that the foregoing specified software and hardware aremerely illustrative, as other versions of software and hardware may beemployed to provide similar functionality to that described hereinwithout departing from the scope and spirit of the invention.

Generally, aspects of the principles and teachings of the embodimentsdisclosed herein may be practice using hardware, software, or anycombination of software and hardware, including use of softwarecomponents, modules, and applications running on physical, such as a CPUof a computer or server, or virtual machines. In addition, embeddedsystems may be implemented to perform aspects of the embodiments,

Thus, embodiments of this invention may be used as or to support asoftware program executed upon some form of processing core (such as theCPU of a computer) or otherwise implemented or realized upon or within amachine-readable medium. A machine-readable medium includes any tangiblemechanism for storing information in a form readable by a machine (e.g.,a computer, server, embedded system, etc.). For example, amachine-readable medium can include such as a read only memory (ROM); arandom access memory (RAM); a magnetic disk storage media; an opticalstorage media; and a flash memory device, etc.

In the Figures, the elements in some cases may each have a samereference number or a different reference number to suggest that theelements represented could be different and/or similar. However, anelement may be flexible enough to have different implementations andwork with some or all of the systems shown or described herein. Thevarious elements shown in the figures may be the same or different.Which one is referred to as a first element and which is called a secondelement is arbitrary.

In the description and claims, the terms “coupled” and “connected,”along with their derivatives, may be used. It should be understood thatthese terms are not intended as synonyms for each other. Rather, inparticular embodiments, “connected” may be used to indicate that two ormore elements are in direct physical or electrical contact with eachother. “Coupled” may mean that two or more elements are in directphysical or electrical contact. However, “coupled” may also mean thattwo or more elements are not in direct contact with each other, but yetstill co-operate or interact with each other.

An embodiment is an implementation or example of the inventions.Reference in the specification to “an embodiment,” “one embodiment,”“some embodiments,” or “other embodiments” means that a particularfeature, structure, or characteristic described in connection with theembodiments is included in at least some embodiments, but notnecessarily all embodiments, of the inventions. The various appearances“an embodiment,” “one embodiment,” or “some embodiments” are notnecessarily all referring to the same embodiments.

Not all components, features, structures, characteristics, etc.described and illustrated herein need be included in a particularembodiment or embodiments. If the specification states a component,feature, structure, or characteristic “may”, “might”, “can” or “could”be included, for example, that particular component, feature, structure,or characteristic is not required to be included. If the specificationor claim refers to “a” or “an” element, that does not mean there is onlyone of the element. If the specification or claims refer to “anadditional” element, that does not preclude there being more than one ofthe additional element.

The above description of illustrated embodiments of the invention,including what is described in the Abstract, is not intended to beexhaustive or to limit the invention to the precise forms disclosed.While specific embodiments of, and examples for, the invention aredescribed herein for illustrative purposes, various equivalentmodifications are possible within the scope of the invention, as thoseskilled in the relevant art will recognize.

These modifications can be made to the invention in light of the abovedetailed description. The terms used in the following claims should notbe construed to limit the invention to the specific embodimentsdisclosed in the specification and the drawings. Rather, the scope ofthe invention is to be determined entirely by the following claims,which are to be construed in accordance with established doctrines ofclaim interpretation.

We claim:
 1. A web-services method, comprising: receiving a user login;provide available domains associated with a user's accounts; receiving aselection of at least one of the available domains; receiving accountinformation corresponding to the user; registering the selectedavailable domain with the user's account.